\section{The Spring RTS platform}
Spring RTS\footnote{\url{http://springrts.com/}} is an open source platform for
developing Real Time Strategy games (RTS). The framework provides the engine
that controls the 3D rendering, the movements, the communication over TCP/IP and
all the elements a modern RTS has to implement. Gamers and modders develop
their own games by means of different tools. It is inspired in a 1997 game
called \emph{Total
Annihilation}\footnote{\url{http://en.wikipedia.org/wiki/Total\_Annihilation}}.

\begin{figure}[htp]
	\begin{center}
		\includegraphics[width=10cm]{images/SpringRTSScreenshot.png}
	\end{center}
	\caption{Screenshot of an in progress game in the SpringRTS platform}
	\label{fig:springscreenshot}
\end{figure}

\subsection{World description}
The world in which we are going to {\it work} can be explained splitting its
constraints in two groups, constraints related to other players and constraints
 not directly directed to other players.

\subsubsection{Constraints related to other players}

Here we can find the different types of units and buildings available.
Buildings are the structures that provides more options to the player, like the 
possibility to evolve or the ability to create new units(barracks allow to create soldiers, etc.).
Also we have mobile units, usually this kind of games has a vast option of different units, 
flying units (planes, helicopters), land units (tanks, soldiers), aquatic units (ships, sea animals), 
sub-aquatic units (submarines, squids). Each unit has its own constrictions, like non aquatic units 
are not able to cross rivers, etc.
Related to other players we include all the limitations related to the weapons. RTS games try to have
a realistic treatment of the physics, it includes the weapons physics like not being able to kill a plane
with a terrain-terrain weapon, etc.
Another important thing is the Friendly fire, even most of the games there is not the possibility to shot
 your own or your allies units in the aim of being {\it real} there is always the possibility having your
 own units by the effects of an own bomb.

\subsubsection{Constraints not related to other players}
 The game environment defines different types of physics. In SpringRTS there are
 the sky where only can move flying units, the ground that can be plain or can
 be a mountain or even water which makes more difficult to walk through. 
Another important constraint is the needs and resources. To be able to construct
your own units there is always a need, energy or mineral. But that needs are
related to some resource, and resources are sometimes finite.
The existence or not of what is called Fog of War, is an important constraint
due to the localitzation of enemies units
or resources will be easier or not. Fog of War is layer that hides elements that
are not in the visual field of our own units. In our case the Fog of War let us
see the environment but not our enemies units.




\subsection{Layers}
The world where the units in the game live can be decomposed in two layers, the
ground layer and the air layer. The ground layer is where the vast majority of
units live on and it includes also parts of the map with water instead of
terrain. This layer is not totally flat, it can include elevations of different
heights. Not all parts of this layer are passable by ground units. Some parts
depicted as mountains or big rocks can not be climbed and should be marked as
impassable by our agents' world representation.

The air layer is the layer where the flying units move around. It is ``above''
the ground layer without an explicit height, all units in this layer are
elevated with respect to the ground units. This layer is totally flat, either
you are in the air layer and move around the horizontal coordinates or you are
in the ground layer with its own rules. Units in this layer are not impeded to
pass over the impassable terrain sections of the ground layer. Basically there
is no movement restriction in the air layer.

%Ho he eliminat ja uqe més o menys s'explicava a un apartat anterior (sergi)
%\subsection{Resources}
%Units in this game need two types of resources, energy and mineral.
% TODO. Terminar esta sección jugando un poco con el juego y viendo que
% peculiaridades tiene cada uno.


\subsection{Scenario definition}
% Aquí tenemos que escribir cómo se define un escenario, que reglas tiene, como
% se definen las unidades que participan, etc\ldots

\subsubsection{Mod description}
Traditionally, mods constitute alterations of a game that change the way it
works.  But in Spring RTS, this term refers to a game in its own right that runs
on the Spring engine.

For this work we chosen XTA\footnote{\url{http://springrts.com/wiki/XTA}},
originally developed as a Total Annihilation mod by the Swedish Yankspankers,
this mod is the Original Public Mod released with first versions of Spring.
Although development of this mod by the SYs has stopped a while ago, it is still
played and actively developed by the community.

Peculiarities of this mod that makes it very interesting to develop our
multi-agent system are that it is role balanced, each player starts the game
with a commander/constructor unit, all constructors can build all labs and
commanders are strong.

A balanced mod is a mod where every unit has a role, and no unit has every role.
In addition, very few units get truly obsolete as a game progresses.

It is important to take in account that each player starts the game with a
commander unit with constructor functions that are also strong, because it
allows to put in practice as fight roles as construction roles, from the game
starting.

With few exceptions, all constructors can build all labs. This opens new tactics
such as two or more players can evolute technologically together and quickly.

\subsubsection{General map information}

As usual, the maps packs information about relieve and textures, but also take
care of color and resources settings. All maps are based on three
sub-maps\footnote{\url{http://springrts.com/wiki/Create_maps}}: texture map,
heigh map and metal map; and several parameters.

The first one (shown in \autoref{fig:textureMap}) is a texture image, with only two requirements: originality and
measures. Image's width and height must be an exact multiple of 1024 pixels.

\begin{figure}[htp]
	\begin{center}
		\includegraphics[width=10cm]{images/textureMap.png}
	\end{center}
	\caption{Texture map of FolsomDamFinal map}
	\label{fig:textureMap}
\end{figure}

The second one, the heigh map (shown in \autoref{fig:heightMap}), defines the
relief by grayscale image. Where white areas are the tops of mountains and
black areas are the sea floor or the bottom of valleys.  This map has measures
requirements too. The image must be exactly one eighth (1/8) of the size of the
texture map + 1 pixel. For instance, if the dimensions of texture map are ``4096
by 8192'', the heigh map height and with would be ``513 by 1025''.

\begin{figure}[htp]
	\begin{center}
		\includegraphics[width=10cm]{images/heightMap.png}
	\end{center}
	\caption{Colored height map of FolsomDamFinal map}
	\label{fig:heightMap}
\end{figure}

And the last one, the metal map, is an image with same size as the height map
where we have to paint down red to represent metal. So a red spot that is
RGB(50,0,0) will provide about a 5th of the metal patch of red RGB(255,0,0) will
give. On this map we can also place green pixels. Each green pixel will create 1
geothermal vent.

In addition, it is possible to define all colours of the map, including air and
water colours, and other parameters like the sun position. But the parameters
with most importance during the game are gravity and resource settings:

\begin{itemize}
	\item {\it MaxMetal}: Maximum amount of metal we will gain from one game
		square in 1 second from an area of metal that had a red value of 255 in
		your metal map.
	\item {\it TidalStrength}: Determines how much energy tidal generators will
		produce.
	\item {\it ExtractorRadius}: Area that is harvested by 1 metal extractor.
	\item {\it Gravity}: Affects ballistics and how far units fly after an
		explosion.
\end{itemize}


\subsection{Interfacing, communications and APIs}
% Aquí tenemos que contar las cosas que hayamos investigado acerca del API, un
% pequeño diagrama de cómo tendría que interactuar la plataforma de
% multiagentes, etc\ldots
Spring provides an infrastructure to easily connect new AI modules through any
of its wrapper interfaces. Those wrappers encapsulate the SpringRTS interface in
the chosen programming language. One of those wrappers is the Java wrapper that
we will use when developing our own system.
\subsubsection{Communication with the platform}
\begin{itemize}
	\item {\bf Events}. Everything remarkable in SpringRTS is an event. Whenever an enemy unit is
		spotted, a new unit is created or a building finished, SpringRTS notifies the AI
		with a new event. Those events are sent through a Java interface and should be
		captured by our AI module. 
	\item {\bf Callbacks}. This is the channel through which our module
		communicates with the SpringRTS Platform when requesting actions. There
		is a callback object that holds the reference for this communicating
		channel. Here we can distinguish between two types of communication,
		whenever we need information about the environment (read-only) and when
		we want to perform actions that change the world. For the former,
		especial functions are provided to ask the platform. For the latter, all
		the changing world actions must be packed in a special structure called
		Command that is sent to the platform.
\end{itemize}

\subsubsection{Task to be implemented}
When implementing our AI module we will have to develop three layers to
encapsulate our agents.
\begin{description}
	\item[First] Create the basic overlay for the AI. Spring provides an
		interface defining which events and which actions the SpringRTS platform
		generates or can receive. Not all of those functions will be useful to
		our agents, so creating the overlay and stub code for these functions is
		something we have to create.
	\item[Second] Routing messages. The SpringRTS will act as the sensory system
		to our agents. We need thus to route those messages to the specific
		agent or agents responsible of those messages. This is the bridge
		between the SpringRTS and our Agent Architecture.
	\item[Third] The Agent architecture. Finally here we have to interface with
		the chosen platform for our multi-agent solution. We have the message,
		we know which agent have to receive it and the only thing remaining is
		to send physically this message to the receiver.
\end{description}

All this functionality has to be packed into a jar, create a Lua descriptor for
the AI agent and put into the AI directory of the SpringRTS. The next time you
fire the game, you'll have this agent for choosing among the AI contenders.



